The following glossary of terms can be referred to by the reader to assist in understanding acronyms and terms used herein.
AcronymDefinitionCDMACode Division Multiple AccessCOPSCommon Open Policy Service protocolESMEExternal Short Messaging EntityFOFixed Network OriginatedFTFixed Network TerminatedGSMGlobal System for Mobile communication. The dominantmobile radio technology at the time of writing.IMSIInternational Mobile Subscriber IdentityHLRHome Location Register. This is the GSM term for the net-work database that holds those subscription details necessary to deliver service. For example the network address of the node currently serving the subscriber, the services subscribed to, and what supplementary services the subscriber has acti-vated. The American standards have an equivalent database.MAPMobile Application Part. The protocol layer that sits betweenthe top of the SS7 stack (TCAP) and the SMS application protocol. In general I refer to GSM MAP, but the equivalent protocol layer exists in the American standards too.MOMobile Originated.MTMobile TerminatedMSMobile Station. The combination of a subscriber identity module (SIM) with a handset to create a working mobile telephone.MSCMobile Switching CenterMMSMultimedia Message ServiceMSISDNMobile Station Integrated Services Digital NetworkMWDMessage Waiting Data. That part of the HLR database that records for each mobile subscriber the list of addresses of service centres that have messages queued for the subscriber. When the subscriber connects to the network and becomes reachable the HLR notifies every service centre in the list for that subscriber that the subscriber is now available to receivemessages.PDPA COPS Policy Definition PointPEPA COPS Policy Enforcement PointSIGTRANSigtran is a working group of the IETF, formed in 1999, and tasked with defining an architecture for the transport of real-time signalling data over IP networks. Its work culmi-nated in not just the architecture, but also the definition of a suite of protocols to carry SS7 and ISDN messages over IP.This protocol suite is made up of a new transport layer—theStream Control Transmission Protocol (SCTP)—and a set of User Adaptation (UA) layers which mimic the services ofthe lower layers of SS7 and ISDN. In this paper the term SIGTRAN is used to refer to the stack rather than the com-mittee that invented it.SMShort MessageSMPPShort Message Peer to Peer protocolSMSShort Message ServiceSMSCShort Message Service CentreSRStatus Report. This is the GSM MAP term for a notificationsent back to the originator of an SM informing them of the progress to date in attempting delivery. In this paper I intend the term to include equivalent messages in other protocols—such as SMPP Delivery Receipts.SS7Signalling System 7, a telecommunications protocol defined by the International Telecommunication Union (ITU).TDMATime Division Multiple AccessUDHUser Data Header
The following documents are referred to in this document by their respective reference numbers. The below cited documents can help the reader to understand this document and each is incorporated herein, in its entirety, by reference.                [1] Universal Mobile Telecommunications System (UMTS); Technical realization of the Short Message Service (SMS), V6.5.0, ETSI TS 23 040, 3GPP, September 2004        [2] Mobile Application Part (MAP) Specification, 6.7.0, ETSI TS 29 002, September 2004        [3] Short Message Peer to Peer; Protocol Specification v3.4, 1.2, SMS Forum, October 1999        [4] Short Message Peer to Peer; Protocol Specification v5.0, SMS Forum, February 2003        
FIG. 1 is a schematic representation of an exemplary existing messaging service architecture 100. In the architecture 100 represented in FIG. 1 both a router 104 and a Short Message Service Center (SMSC) 103 have International Telecommunication Union (ITU) Signaling System 7 (SS7) or SIGTRAN interfaces to a mobile network (a.k.a. PLMN) 105. Mobile Application Part (MAP) is used over SS7 or SIGTRAN (see references [1] and [2]). The interface between the router 104 and the SMSC 103 typically uses the same protocol stack as that used to connect these systems to the mobile network 105. The paragraphs that follow describe the main traffic flows through the exemplary messaging service architecture 100.
MO-MT Messages (a.k.a. Person to Person Messages)
MO SM are handled initially by the router 104. Typically 80% or more of MT SM are delivered on the first attempt so the router 104 will immediately attempt to deliver 112 the SM to the intended receiver. If the delivery attempt fails then the router passes 110 the SM to the SMSC 103. The SMSC 103 stores the SM and at a later time makes further attempts to deliver it 109 to the MT receiver.
In this architecture it is possible for MO SM to bypass the router (not illustrated) if the originating mobile is programmed with the address of the SMSC 103 rather than the address of the router 104. Although this is discouraged, it nonetheless is fairly common.
MO-FT Messages (a.k.a. Person to Application Messages)
MO SM 111 are handled initially by the router 104. Typically in excess of 95% FT SM are delivered at the first attempt so the router 104 will immediately attempt to deliver 108 the SM to the intended receiver via the gateway 102. If the delivery attempt fails then the router 104 passes 110 the SM to the SMSC 103. The SMSC 103 stores the SM and at a later time makes further attempts to deliver it 107. All MO SMS-COMMAND (or the CMDA, TDMA or other protocol equivalents) operations messages are sent to the SMSC 103.
FO-MT Messages (a.k.a. Application to Person Messages)
FO SM are initially handled by the gateway 102. If the originator selects single-shot quality of service then the SM is forwarded 113 directly to a router 104 for delivery. If store-and-forward quality of service is selected then the gateway 102 forwards 114 the SM to the SMSC 103 instead. All messages containing update, delete and enquiry operations are sent to the SMSC 103.
Alternatively the gateway 102 can send 113 all FO-MT SM to a router 104 for an initial delivery attempt, and if this fails the gateway 102 can forward them to the SMSC 114 for storage and later re-attempted delivery 109.
Shortcomings of the Existing Implementations
The well known implementations of the messaging architecture suffer from a number of shortcomings. These include:                The protocol used between the router 104 and the SMSC 103 is in most cases MAP over SS7. SS7 connectivity tends to be expensive and restricted in bandwidth. Some of the drawbacks of this protocol will be alleviated by the rollout of SIGTRAN, but in many networks this is still years away.        Because the SMSC 103 does not know what the router 104 has done with the message before forwarding it, the SMSC 103 has to make an attempt to deliver the message to determine the message status, register itself with the HLR and determine what retry schedule to use for the message.        Because the SMSC 103 does not know what the router 104 has done with the message before forwarding it, the SMSC 103 does not know if pre-pay charges have been applied to the SM or not.        Load balancing between the elements of the solution is difficult to achieve because the protocols used do not support congestion reporting.        Load balancing between elements of the solution makes the routing of queries, updates and deletion commands difficult. Some implementations address this by simply copying the commands to every SMSC, but this is inefficient.        Most implementations of this architecture do not cater effectively for the situation where Status Reports are generated by the router or gateway but cannot be delivered.        The GSM SMS standards allow the originator of an SM to specify that the recipient should be allowed to reply to the SM using the original originators home SMSC 103. For this to work the SMS must keep track of who has sent such SM to whom and to allow exactly one reply. The router 104 needs to be able to police these replies, but it is also necessary for the SMSC 103 to have this information. Existing implementations do not provide a means for the SMSC 103 and router 104 to share this information.        Typically implementations of the messaging architecture do not handle multi-part messages (i.e. concatenated) well and this can result in either parallel delivery attempts or out of sequence delivery.        
The remainder of this section describes each of these issues in turn in more detail. In this document references are made that are specific to GSM. Except where otherwise stated, the analogous technologies related to other well known mobile telephony (e.g. TDMA, CDMA) and message services apply equally.
Interconnect Protocol
Because all SMSC 103 have a MAP/SS7 interface router 104 products use this as the basic interconnect between the router 104 and the SMSC 103. Use of this protocol stack imposes a number of limitations on the interface between routers 104 and SMSC 103:                MAP is network specific. You need different protocol implementations for different mobile networks (e.g. GSM, CDMA, TDMA)        The SS7 stack imposes limitations on the size of the messages that can be sent without segmentation. Existing implementations are supposed to, but may not cope with very large “short” messages. This limits the extent to which MAP messages can be safely extended even when the approved extension mechanism is used.        The basic SS7 infrastructure is expensive for a given bandwidth when compared with TCP/IP over a LAN.        There is no easy way of adding proprietary operations to MAP.        
The de-facto standard for connecting gateways 102 to SMSC 103 is SMPP v3.4, see reference [3]. This protocol has some limitations but is extensible and is widely supported. SMPP v5 (see reference [4]) is technically a superior protocol to SMPP v3.4 that addresses some, but not all, of the above described limitations.
Superfluous Deliveries
When an SMSC 103 receives an SM from a router 104 or a gateway 102 most SMSC 103 immediately attempt to deliver the SM. If the router 104 or the gateway 102 did not attempt to deliver the SM then this is not a problem, but if it did then this immediate delivery attempt often represents a wasted effort because it will probably fail for the same reason as the failed router or gateway delivery attempt.
In a typical GSM network the breakdown of delivery failures for delivery attempts to the mobile network is as follows:
Percentage of allErrordelivery failuresUnknown Subscriber (Permanent Error)2Call Barred by Operator (Permanent Error)1Memory Capacity Exceeded20Absent Subscriber - IMSI Detached64Absent Subscriber - Paging Failure3System Failure9Error in MS1
So 3% of MT delivery attempts fail with permanent errors and the SM should be discarded by the router 104 or the gateway 102 rather than forwarded to an SMSC 103. Of the SM forwarded 84% failed their original delivery attempt for reasons that will cause an immediate retry by the SMSC 103 to terminate with an error indication from the HLR. However this retry/delivery attempt must be made in order to register the SMSC 103 in the MWD of the HLR. The remaining 13% of failures are errors that if delivery is immediately retried will result in both a sendRoutinglnfoForSM operation and a mt-ForwardSM operation being sent. In many of these cases this immediate retry will probably succeed.
Congestion Management
In a heavily loaded network both routers 104 and gateways 102 need to direct traffic to those delivery & storage systems that still have capacity to spare. Although SS7 adequately handles the situation where a system has reached capacity it does not provide adequate facilities to allow one application to signal its load state to another system. Standard SMPP v3.4 has no overload handling mechanism.
Multiple Parallel Deliveries
Mobile networks generally do not allow the delivery of multiple short messages to an MS in parallel. One of the problems that a router based load sharing architecture introduces is that SM for a single MS can end up on multiple SMSC 103. If the SMSC 103 all register with the HLR to receive alerts then when the MS becomes available all of the SMSC 103 attempt delivery to it at the same time. This typically results in one SMSC 103 succeeding and the others all receiving error indications.
Routing of Commands and Network Alerts
The dynamic load sharing of messages between multiple SMSC 103 creates difficulties for routers 104 and gateways 102 when they need to send delete, query or update commands for an SM to the SMSC 103 holding the message.
Addressing the problem of superfluous deliveries discussed above can result in the router 104 having difficulty knowing which of multiple SMSC 103 it needs to trigger delivery from when it receives an alert from the network.
Charging
Many networks charge pre-pay subscribers for their MO SM in real-time before the first attempt is made to deliver the SM. However if the first delivery attempt fails and the SM is forwarded to the SMSC 103 which also fails to deliver it then it may be necessary for the SMSC 103 to issue a refund. Some pre-pay systems may require the reference of the original charge in order to issue the refund. Current router 104 implementations do not convey this information to SMSC 103. Also in some networks it may be desirable to pass messages that cannot be charged for immediately to the SMSC 103 to store until such time as the charge can be successfully made (e.g. temporary unavailability of the charging system). In this case the SMSC 103 needs to be able to discriminate between those SM that have been charged for and those that have not.
Many networks charge for reverse charge SM from applications to mobiles in real-time just before they are delivered. If an SM cannot be charged for then the delivery attempt must be aborted and the SM sent to an SMSC 103 for storage and delivery at a later date. If the SMSC 103 is going to make deliveries directly then it needs to know which messages have been charged for and which have not. Current router 104 implementations do not convey this information to SMSC.
Status Reports
Most routers 104 that have the capability to deliver SM are also capable of generating SR to report the outcome of a delivery attempt. If the original SM submitter is no longer reachable at that point then the SR must either be discarded or the router 104 must save it and retry delivering it later. Neither of these options is desirable.
Most gateways 102 do not currently generate SR. They leave this to the SMSC 103 that is delivering through them. However in theory future gateways 102 could generate SR and in this case they will also need the capability to forward SR that they cannot deliver to SMSC 103.
Virtual Mobile Handling
There are many implementations of the concept of attaching a fixed network application to a mobile network as if it were a mobile. This is generally achieved by adding a device to the SS7 network that emulates an MSC that is supporting a population of “mobiles” that are actually fixed network devices.
FIG. 2 is a schematic representation of message flow sequence 200 in an exemplary virtual mobile service. When the Virtual Mobile feature is used in a router the fact that the original SM was a virtual mobile SM is lost when the SM is forwarded to an SMSC. This means that the SM arrives at the SMSC as if it was a normal MO SM and will almost certainly be rejected by either the MSISDN or IMSI barring checks in the SMSC (because the SM was originated by the subscriber of another network).
The originating SMSC 204 has accepted an SM and is attempting to deliver it to a fixed network application 203 that is masquerading as a Mobile Station.                1. The originating SMSC 204 sends the SM over SS7/SIGTRAN 207 to a router 202 that is emulating and MSC over the mobile network backbone. Typically this will involve the originating SMSC 204 first obtaining the address of the router 202 by interrogating a real (or simulated) HLR (not illustrated). Then the message is sent 207 to the router 202. This usually means exiting the home network of the originating SMSC 204 through one gateway switch and entering the destination network through another (not illustrated).        2. The router 202 attempts to deliver 206 (either directly or via a gateway 208) the SM to the application 203, but is unsuccessful.        3. The router 202 forwards 205 the SM to another SMSC 201 that for storage and delivery at a later date. The router 202 acknowledges receipt of the message to the originating SMSC 204. This step is typically fails as the router 202 fails to inform the SMSC 201 that the SM is a virtual mobile message rather than a normal message and the SMSC 201 rejects it. If the SMSC 201 accepts the SM the SMSC 201 will subsequently attempt to deliver 209 it (either directly or via a gateway 208) to the application emulating an MS 203.        
An alternative implementation is for the router 202 to return an error to the originating SMSC 204 if the delivery attempt to the application (see reference [2]) is unsuccessful. This puts the onus for retrying delivery on the originating SMSC 204. This latter solution puts more load on the network and particularly on the inter-network gateway and the HLR.
Replies
Referring again to FIG. 1, the router 104 keeps track of those SM that it has delivered and that specified that a reply was allowed via the router 104 (for example, in a GSM SMS this is done by setting the TP-REPLY-PATH field) and so do the SMSC 103 for the SM that they handle. This means that when a reply is sent back to the SMSC 103 or router 104 that delivered the original message special handling can be invoked to ensure that the reply is accepted. If the router 104 fails to deliver the reply it must forward it to the SMSC 103. However the SMSC 103 will not recognize the SM as a reply (if it did not handle the original SM) and will reject it.
Concatenated SM Handling
Problems can arise when the router 104 attempts to deliver concatenated SM. If for example the first part (i.e. part 1) is successfully delivered by the router 104, but part 2 cannot be delivered then part 2 is sent to the SMSC 103. If part 3 then arrives at the router 104 and is delivered by the router 104, part 3 may arrive at the MS before part 2. Typically this happens because the router 104 drops the dialogue to the MS after part 1, and part 2 fails because the MSC is still in the process of tearing down the air channel when part 2 arrives.